— CEN/TR 16931-6 1 Electronic invoicing - Part 6: Result of the test of EN 16931-1 with respect to its practical application for an end user - Testing methodology

According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

Introduction

The European Commission estimates that “The mass adoption of e-invoicing within the EU would lead to significant economic benefits and it is estimated that moving from paper to e-invoices will generate savings of around EUR 240 billion over a six-year period”2 . Based on this recognition “The Commission wants to see e-invoicing become the predominant method of invoicing by 2020 in Europe.”

To achieve this goal, Directive 2014/55/EU [1] on electronic invoicing in public procurement aims at facilitating the use of electronic invoices by economic operators when supplying goods, works and services to the public administration. The Directive sets out the legal framework for the establishment and use of a European Standard (EN) for the semantic data model of the core elements of an electronic invoice.

The semantic data model of the core elements of an electronic invoice – the core invoice model – as described in this document is based on the proposition that a quite limited, but sufficient set of information elements can be defined that supports generally applicable invoice-related functionalities. These functionalities are described in Clause 5. The core invoice model, as described in Clause 6, contains information elements that are commonly used and accepted including those that are legally required.

It is expected that in most situations, business partners would use the core invoice model exclusively and the invoices they send or receive would not contain any additional structured information elements. However, in some sectors or situations where there are specific information requirements, the required information may be conveyed in the form of unstructured text. Unstructured text has the drawback in that it cannot be processed automatically and therefore requires human intervention. Alternatively, the specific information requirements can be implemented using information elements that extend the core invoice model. Any such extension needs to respect the semantic definitions in the core invoice model. Only business partners that are part of such a sector or supply chain would be expected to be able to process the extensions. In these circumstances, it should be possible to define a number of required additional information elements whilst still utilizing the core invoice model concept.

In line with Directive 2014/55/EU [1] and after the publication of the reference to this document in the Official Journal of the European Union, all contracting authorities and contracting entities in the EU will be obliged to be able to receive and process an e-invoice as long as it contains all of the (applicable) core elements of an invoice defined in this European Standard (and provided that it is represented in any of the syntaxes identified in the related Technical Specification CEN/TS 16931-2 “List of syntaxes that comply with EN 16931-1” in accordance with the request referred to in paragraph 1 of article 3 of the Directive 2014/55/EU. The inclusion of any additional information which is not contained in the core model will be at the sender’s discretion and contained in unstructured text or in an extension, by agreement with the contracting entity. The inclusion of any extension in an e-invoice will be optional, and it will not form an integral part of the European Standard. See Clause 4 below for further detail on extensions.

By ensuring semantic interoperability of electronic invoices, the European Standard and its ancillary European standardization deliverables will serve to remove market barriers and obstacles to trade deriving from the existence of various national rules and standards – and thus contribute to the goals set by the European Commission.

1 Scope

This European Standard establishes a semantic data model of the core elements of an electronic invoice. The semantic model includes only the essential information elements that an electronic invoice needs to ensure legal (including fiscal) compliance and to enable interoperability for cross-border, cross sector and for domestic trade. The semantic model may be used by organizations in the private and the public sector for public procurement invoicing. It may also be used for invoicing between private sector enterprises. It has not been specifically designed for invoicing consumers.

This European Standard complies at least with the following criteria:

— it is technologically neutral;

— it is compatible with relevant international standards on electronic invoicing;

— the application of this standard should comply with the requirements for the protection of personal data of Directive 95/46/EC, having due regard to the principles of privacy and data protection by-design, data minimization, purpose limitation, necessity and proportionality;

— it is consistent with the relevant provisions of Directive 2006/112/EC [2];

— it allows for the establishment of practical, user-friendly, flexible and cost-efficient electronic invoicing systems;

— it takes into account the special needs of small and medium-sized enterprises as well as of sub-central contracting authorities and contracting entities;

— it is suitable for use in commercial transactions between enterprises.

2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

EN ISO 3166‑1, Codes for the representation of names of countries and their subdivisions — Part 1: Country codes (ISO 3166-1)

ISO 4217, Codes for the representation of currencies

ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates and times

ISO 15000‑5, Electronic Business Extensible Markup Language (ebXML) — Part 5: Core Components Specification (CCS)

ISO/IEC 6523 (all parts), Information technology — Structure for the identification of organizations and organization parts

[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-16T22:40:00'FvB
NOTE: '#2']IEEE/ISO/IEC 60559-2020 - ISO/IEC/IEEE International Standard - Floating-point arithmetic

3 Terms and definitions

For the purposes of this document, the following terms and definitions apply.

NOTEBusiness terms that are part of the semantic model are defined in the model itself.

3.1

electronic invoice

invoice that has been issued, transmitted and received in a structured electronic format which allows for its automatic and electronic processing

[SOURCE: Directive 2014/55/EU [1]]

3.2

semantic data model

structured set of logically interrelated information elements

3.3

information element

semantic concept that can be defined independent of any particular representation in a syntax

3.4

structured information element

information element that can be processed automatically

3.5

syntax

machine-readable language or dialect used to represent the information elements contained in an electronic document (e.g. an electronic invoice)

3.6

business term

label assigned to a given information element which is used as a primary reference

3.7

core invoice model

semantic data model of the core elements of an electronic invoice

3.8

core elements of an electronic invoice

set of essential information elements that an electronic invoice may contain in order to enable cross-border interoperability, including the necessary information to ensure legal compliance

3.9

identifier

character string used to establish the identity of, and distinguish uniquely, one instance of an object within an identification scheme from all other objects within the same scheme

Note 1 to entry:An identifier may be a word, number, letter, symbol, or any combination of those, depending on the identification scheme used.

3.10

identification scheme

collection of identifiers applicable for a given type of object governed under a common set of rules

3.11

compliant

some or all features of the core invoice model are used and all rules of the core invoice model are respected

Note 1 to entry: Based on TOGAF definition of a compliant specification [18].

3.12

conformant

all rules of the core invoice model are respected and some additional features not defined in the core invoice model are also used

Note 1 to entry: Based on TOGAF definition of a conformant specification [18].

4 The concept of a core invoice

0.1 The core invoice model as a response to the challenge of interoperability

The establishment of interoperability of business information systems with respect to the exchange of electronic documents such as invoices is viewed by many as a major challenge for the following reasons:

a)the overall business environment is very diverse and consequently so is the information that needs to be exchanged between business partners;

b)documents such as invoices consist of many information elements; attempting to define and standardize all occurring information elements would generate a very large and complex information model that no single organization could implement entirely;

c)even if a complete implementation of such a large model were possible, its implementation across the business environment would be very challenging and costly;

d)as experience shows, business partners in various industry sectors will agree on subsets of the model that are supported by their business information systems. Such variety would work against the principles of using common standards, jeopardize interoperability and result in expensive implementation projects.

This document is based on a different approach. In contrast to collecting and meeting the requirements of all businesses, a semantic model is defined that includes only the essential information elements that an electronic invoice needs to ensure legal (including fiscal) compliance and to enable interoperability for cross-border, cross-sector and domestic trade. The semantic model may be used by public and private sector organizations for public procurement invoicing. It may also be used for invoicing between private sector enterprises.

The result of this approach is a semantic model of core information elements for an electronic invoice, i.e. a core invoice model. The following guiding principles form the basis of the core invoice model:

1)it should be easier to prepare and send, as well as to receive and process electronic invoices when compared to paper invoices;

2)the use of standardized information elements should make electronic invoice processing more efficient than processing paper invoices;

3)compliance with the core invoice model should mean that business partners should be able to interpret and understand the content of an electronic invoice at the semantic level without prior consultation or bilateral agreements;

4)invoices should be composed of structured information elements to enable efficient and automatic processing;

5)invoice processing software should be able to present all information elements in the core invoice model, and automatically process all structured data;

6)the use of structured data should result in optimized business processes;

7)the core invoice model makes no assumption about the method by which an invoice is created, delivered and processed. It may be exchanged directly between business partners or exchanged using an intermediary service provider;

8) the core invoice model makes no assumption about the syntax or transmission technology used. Senders and receivers of e-invoices shall ensure the authenticity and integrity of the invoice according to relevant regulations. Mapping to several syntaxes is provided in CEN/TS 16931-3 from subpart 2 onward.

0.2 Contents of the core invoice model

The core invoice model is based on the proposition that a quite limited, but nevertheless consists of a sufficient set of information elements which can be defined and support generally applicable invoice-related functionalities. These functionalities include invoice issuance and delivery, invoice validation, accounting, VAT reporting, payment and auditing. The core invoice model contains information elements that are commonly used and accepted, including those that are legally required.

If all organisations in Europe were to implement the core invoice model in their business information systems using the specified information elements, then sending, receiving and processing invoices electronically, without human intervention, would be possible. There would be no need for onerous pre-negotiated bilateral agreements between organizations on the actual semantic content of the invoice and its exchange. The only assumption is the existence of a normal business contract or trading agreement. The core invoice model supports a set of invoice functions, as specified in Clause 5 below.

The set of information elements that are contained in the core invoice model is commonly considered to consist of two parts: a legal part and a common part.

The legal part of the core invoice model supports the observance of both tax and commercial legal and regulatory requirements pertaining to electronic invoicing commonly in force throughout the EU.

The common part contains commonly used and accepted information elements that are not sector or country specific.

A specific information element may be correctly allocated to one or both parts. Therefore categorizing elements with respect to these parts in the semantic model is not considered to be meaningful.

To fulfil the requirements above, judgment has had to be made on the selection of the information elements to be included in the core invoice model. First, for the legal part requirements, the selection has been made regarding the information elements required on a mandatory basis by EU VAT Directives and individual state law, whether local VAT regulations, or any other local legal provision (regulatory, contractual company law, laws on business documents, etc.). In some cases, those information elements that are exclusively confined to a single or very small number of countries and therefore fall outside the doctrine of ‘commonly in force throughout the EU’ have not been included in the core invoice model. Secondly, the elements selected to satisfy the requirements of the common part form a justifiable selection of requirements required in commercial practice.

An important criterion when to include an information element in the core invoice model that is above and beyond one that is legally required is whether it can be assumed that the buyer’s information system can process (or otherwise handle) such an element. If the business information systems of most buyers are incapable of processing such an information element, that element should not be part of the core invoice model. If such an element is nevertheless required in a specific context, it should be contained within an extension to the core invoice model, either specific to a sector or country. The methodology to create extensions is described in CEN/TR 1693
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2021-02-04T14:38:00'FvB
NOTE: 'Typo']1-5. When experience shows that an extension is frequently used, then such an extension could be added as information elements to the core invoice model in a later version rather than continuing to be handled in an extension.

0.3 How to use and extend the core invoice model

As stated in the previous subclause, the core invoice model is intended to be used for all generally applicable invoicing processes. In most situations, business partners would use the core invoice model exclusively and the invoices they send or receive would contain only structured information elements defined in the model. Where a dedicated field exists for a business term or piece of data, this field shall be used for the information content instead of using a textual field.

There are however circumstances where the trading partners may wish to: Either 1. restrict the information elements to be used in an e-invoice or 2. to provide additional information elements. The first requirement is satisfied using a Core Invoice Usage Specification (CIUS). The second requirement is satisfied using an extension specified in an Extension Specification.

In many trading situations, it may be appropriate to restrict the use of conditional information elements present in the core invoice model in some way to support automated processing. The use of a CIUS to specify these requirements is described in Clause 7 below. The CIUS is a specification that provides a seller with detailed guidance, explanations and examples, relating to the actual implementation and use of the information elements in the core invoice model in a specific trading situation.

Typically, a CIUS will be created by a contracting entity (buyer) in relation to its own supply chain or by a group of contracting entities wishing to achieve consistency in the way that the information elements in the core invoice model are to be used by sellers trading with an identified sector or community of buyers. The requirements set out in such a CIUS will be communicated to sellers or placed on a website, and may be included in the contractual documentation between the parties. Alternatively, a CIUS may be created by a group of sellers and agreed in turn by their buyer or buyers in the context of a specific industry or supply chain.

A CIUS is a set of usage guidelines or restrictions made to the core invoice model that will still produce an invoice instance that is fully compliant with the core invoice model set out in this document. That means that a receiver of an invoice document instance that has been created in compliance with a CIUS is still able to receive and process it in accordance with the rules defined for the core invoice model.

In some sectors or situations where there are specific additional information requirements, the required information may be conveyed in the form of unstructured text. Unstructured text has the drawback in that it cannot be processed automatically and therefore requires human intervention.

Alternatively, the specific information requirements can be implemented using an extension containing information elements that extend the core invoice model (See CEN/TR 16931-5 for the methodology applicable to the use of extensions). Any such extension shall not infringe or contradict the semantic definitions in the core invoice model. Only business partners that are part of such a sector or supply chain would be expected to be able to process the extensions. In these circumstances, it is possible to carefully define the required additional information elements, whilst still utilizing the core invoice model concept.

Some extensions are not specific to a single supply chain or industry sector, but may be specific to functions or business processes required by more than one sector. E.g. the vendor managed inventory (VMI) process has been implemented by, for example, the automotive, steel and printing industries. The VMI business process may require additional information elements, not present in the core invoice model. Clearly, similar functions and processes should consistently use the same information elements across Europe.

The development of sector specific or cross-sector extensions should be based on justified business requirements. These can only be gathered by industry experts, (private and public) sector organizations and their customers, who understand those requirements. The semantic model of these additional information elements will need to be defined and registered as an extension with the appropriate organization.

0.4 Compliance

0.5 The business parties involved and their roles and relationships

In the basic purchase-to-pay process there are two business parties, the Customer and the Supplier. Each party may fulfil two or three roles in the process. The Customer party has the role of the Buyer (the commercial role that contracts with a Seller and orders the goods and services) and the Receiver (the operational role that receives the goods and services). The Supplier party has the role of the Seller (the commercial role that is contracted by a Buyer) and the Payee (the role that receives the payment). Both parties are considered to be Taxable persons (the role that declares and pays or reclaims VAT), except for some public entities. The Supplier may delegate the operational aspects of that role to a Tax representative, who declares and pays VAT on his behalf.

1 Figure 1 — Parties and roles

In the core invoice model, it is assumed that the Supplier party combines, by default, the roles of Seller and Payee. Roles may however be outsourced. The role of Payee may be fulfilled by another party, e.g. a factoring service. The same applies to the roles of the Customer (Buyer and Receiver) that may be fulfilled by different parties. It is assumed that the Seller issues the invoice. Note that in certain transactions the Buyer may be liable to pay VAT instead of the Seller.

An invoice consists of a header and one or more line items. All information about the parties is defined at header level.

Table 1 illustrates the different roles in an invoice:

2 Table 1 — Parties and roles

Context	Role	Explanation
Supplier:
Trade	Seller (invoice issuer)	Principal role
Payment	Payee	Additional role, may be a different party from the Seller (e.g. a factoring service)
Tax	Taxable Person (may engage a Tax representative)	Designation for tax purposes
Customer:
Trade	Buyer (invoice receiver)	Principal role
Delivery	Receiver	Additional role, may be a different party from the Buyer (e.g. a subsidiary of the Buyer in another location)
Tax	Taxable Person	Designation for tax purposes

Other parties may also play roles in the invoicing process, such as (e.g. transport) service providers and (e.g. tax) authorities. They are however indirectly involved as an agent or counterpart and not included in the table.

2.1 Business process requirements supported

2.1.1 Introduction

The core invoice model supports a basic purchase-to-pay process. Purchase-to-pay processes can be complex due to logistics, legal, product and technical requirements. Examples of such complex processes are: vendor managed inventory, invoicing on behalf of multiple parties in the same invoice, invoicing complex products or project-related products, or ‘swap’ deals. These processes are out of scope of the core invoice model. However, the core invoice model can be extended to support such processes. The extension methodology is described in CEN/TR 16931-5.

This subclause 5.2 describes the processes that are supported by the core invoice model. These processes include buying, selling, delivering goods and services and payment between Customers and Suppliers and their respective roles. How the invoice and other documents are electronically exchanged is not described in the process models. Parties may handle document exchange with their own resources or outsource (part of) it. See also CEN/TR 16931-4.

The process models focus on the external activities of the parties and do not describe internal activities. Only the activities of the roles listed in Table 1 are modelled, not those of third parties.

The process model diagrams are presented in the Business Process Model and Notation (BPMN) of the Object Management Group (OMG) [12]. A short legend of the symbols used can be found in Annex D.

The process models included in 5.2 are intended to indicate the business contexts that are supported by the core invoice model. The models do not give a full definition of those processes.

The core invoice model shall include elements that allow the trading parties to represent any invoice transaction according to the EU VAT directives and should support the following types of business processes:

— P1: Invoicing of deliveries of goods and services against purchase orders, based on a contract;

— P2: Invoicing deliveries of goods and services based on a contract;

— P3: Invoicing the delivery of an incidental purchase order;

— P4: Pre-payment;

— P5: Spot payment;

— P6: Payment in advance of delivery;

— P7: Invoices with references to a despatch advice;

— P8: Invoices with references to a despatch advice and a receiving advice;

— P9: Credit notes or invoices with negative amounts, issued for a variety of reasons including the return of empty packaging;

— P10: Corrective invoicing (cancellation/correction of an invoice);

— P11: Partial and final invoicing;

— P12: Self billing.

Other processes are not explicitly supported, but the core invoice model may still be applicable. In more complex or advanced processes, however, extensions to the information content of the core invoice model may be needed (see CEN/TR 16931-5).

2.1.2 Invoicing of deliveries against purchase orders, based on a contract (P1)

3 Figure 2 — Invoicing of deliveries against purchase orders, based on a contract

In this process the Buyer and the Seller conclude a formal contract (or there is an assumed contract by legal definition) in which the terms and conditions are stated under which goods and services will be delivered and are paid for. The Buyer orders the goods and services, stating the specifications for goods and services, the quantities and the place and time of delivery. The Seller delivers the ordered goods and services to the Receiver as specified on the purchase order. This delivery
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T17:59:00'FvB
NOTE: '#49']or deliveries is/are then invoiced by the Seller to the Buyer. Finally, the Buyer pays the Payee.

A purchase order is sent by the Buyer as a single document. Depending on the contract between the Seller and the Buyer the purchase order may be confirmed by the Seller or even be the subject of negotiation between Buyer and Seller (not shown in the diagram). The resulting purchase order then may result in one or more deliveries (e.g. regular monthly or periodic supply with multiple deliveries under one PO). Each d
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T17:59:00'FvB
NOTE: '#49']Deliveryies results in an invoice. An invoice may only refer to one
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:00:00'FvB
NOTE: '#49']multiple delivery deliveries and one
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:01:00'FvB
NOTE: '#50']multiple purchase orders.

The
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:01:00'FvB
NOTE: '#49']A delivery may include the pick-up and return of returnable packaging from previous deliveries and, for which a payment (deposit) had previously been made by the Buyer and had been received by the Seller. Depending on the agreement between the Seller and Buyer, this deposit may need to be reimbursed to the Buyer using the invoice to account for reimbursement. The invoice may therefore contain lines with a negative amount. Alternatively, credit notes may be used instead.

In a number of national and legal environments, descriptions of products, names and addresses of parties, and locations are obligatory in the electronic messages. Therefore, textual representation of these objects is included in the core invoice model. In other jurisdictions, the Buyer and the Seller may agree on one or more identification schemes for products, locations, parties and other objects. These schemes remove the need for textual based descriptions and names and addresses of the objects identified. These schemes are usual agreed in advance of the Purchase to Pay process and there are various mechanism used for this. This process is called Master Data Synchronisation. In the core invoice model it is assumed that a Master Data Synchronisation process has not been implemented.

3.0.1 Periodic invoicing of deliveries based on a contract, where no purchase order is required (P2)

4 Figure 3 — Periodic invoicing of deliveries based on a contract

In this process the contract directly triggers the delivery. There is no requirement for a purchase order. This scenario is common in the delivery of utilities, but also in delivery of, e.g. food services to offices, schools and hospitals. Invoices are issued to cover a fixed period of time (which can be different per invoice line) and there are continuously instances of the goods and service being delivered. An invoice may only refer to one contract.

4.0.1 Invoicing the delivery against an incidental purchase order (P3)

5 Figure 4 — Invoicing the delivery against an incidental purchase order

In this process, a separate contract does not exist. Purchase orders are placed over the telephone, using internet or over the counter. The A purchase order serves as the a contract and triggers the
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:03:00'FvB
NOTE: '#49']deliveriesy. Each delivery results in an invoice. The A purchase order may be confirmed by the Seller (not shown in the diagram).

5.0.1 Pre-payment (P4)

6 Figure 5 — Pre-payment

The Buyer orders goods and services. Full payment or part-payment is made in advance of the invoice. The invoice states the amount paid in advance and the amount now due for payment by deducting the amount paid in advance from the invoice total, i.e. the balance. If the balance is positive, there is still an amount of money outstanding to the Seller and a final payment is made. If the balance is negative, an invoice with a negative amount due for payment is sent, or a credit note. The Seller then pays the balance to the Buyer. Each delivery results in an invoice. An invoice may only refer to one delivery and one purchase order.
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-10T18:30:00'FvB
NOTE: '#49']

6.0.1 Spot payment (P5)

7 Figure 6 — Spot-payment

The Buyer purchases goods and services without any prior purchase order or contract (e.g. by ordering over the telephone, internet or over the counter). Payment is made in advance of the invoice, e.g. by means of a credit, debit or payment card or through a payment service provider. Note that sufficient business controls should be present in the administrations of both parties given the absence of written purchase orders. Invoicing may take place before, after or at the same time as the delivery. The invoice refers to the account or card number used for payment and states the amount paid in advance. An invoice may only refer to one delivery
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-10T18:31:00'FvB
NOTE: '#49'].

7.0.1 Payment in advance of delivery, based on a purchase order (P6)

8 Figure 7 — Payment in advance of delivery, based on a purchase order

A Purchase Order is exchanged between the Buyer and the Seller, but it is agreed that invoicing and payment are made in advance of delivery. An invoice may only refer to one purchase order.

8.0.1 Invoices with references to a despatch advice (P7)

9 Figure 8 — Invoices with references to a despatch advice

After receipt of the purchase order the Seller sends a despatch advice in advance of the
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:05:00'FvB
NOTE: '#49']deliveriesy. The despatch advice specifies one delivery. In the invoice a reference is made to the relevant despatch advice(s). The invoice content should reflect the content of despatch advices which it refers to. An invoice may only refer to one
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:05:00'FvB
NOTE: '#50']multiple purchase order and one
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:05:00'FvB
NOTE: '#49']multiple despatch advices.

9.0.1 Invoices with references to a despatch advice and a receiving advice (P8)

10 Figure 9 — Invoices with references to a despatch advice and a receiving advice

After delivery and before the invoice is issued, the Seller waits for a receiving advice from the Receiver, in which the Receiver acknowledges that the goods and services have been received and if there are any issues with the delivery. The Seller bases the invoice on information contained in the receiving advices. The invoice may refer
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:06:00'FvB
NOTE: '#49']to one multiple despatch advices, one multiple receiving advices and may also refer to only one
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:07:00'FvB
NOTE: '#50']multiple purchase orders.

10.0.1 Credit Note or negative invoicing (P9)

11 Figure 10 — Credit Note or negative invoicing

In the case of reimbursement of packaging material or returns, the total amount to be invoiced may be negative. In this case a credit note with a positive total amount may be sent instead of an invoice. The Seller will reimburse the Buyer, either by means of a negative invoice or by means of a credit note. The invoice or credit note may refer to one delivery, one purchase order, one contract and
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-10T18:32:00'FvB
NOTE: '#49, #50']one
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-12-09T12:38:00'FvB
NOTE: 'Consistency']multiple preceding invoices.

On the basis of a commercial agreement the Seller may apply a quarterly or yearly reimbursement (not shown in the diagram). A credit note may also be used in such case.

11.0.1 Corrective invoicing (P10)

12 Figure 11 — Corrective invoicing

Many cases exist where an invoice is disputed and/or may need to be corrected. Product descriptions may be wrong, invoiced quantities may differ from delivered quantities, VAT rates may have changed, etc.

A disputed invoice may be corrected by means of the following mechanisms:

1.the disputed invoice may be replaced completely by first sending an identical credit note or an invoice in which the quantities and thus the line and total amounts have been made negative and then sending the correct invoice

2.alternatively an invoice, credit note or negative invoice may be sent with the difference in quantities and amounts between the correct invoice and the disputed invoice. Such a differential corrective invoice or credit note may contain lines that completely compensate lines in the disputed invoice with the corrected lines.

Corrective invoices and credit notes shall refer to the original invoice.

See Annex A for examples of these correction mechanisms.

12.0.1 Partial and final invoicing (P11)

13 Figure 12 — Partial and final invoicing

In some industries, such as Construction and Utilities, during the period of delivery one or more partial invoices are sent before the final invoice. Partial invoices may be estimates of consumption or requests for pre-payment. In some cases, the pre-payment requests do not state the VAT amounts; those are then only stated on the final invoice.

The final invoice shall refer to the partial invoices.

Note that partial invoices without VAT are not allowed in some member states.

13.0.1 Self-billing (P12)

14 Figure 13 — Self-billing

In a self-billing process, the Buyer sends the invoice to the Seller. Both Buyer and Seller keep their responsibilities, so the invoice is still issued on behalf of the Seller. According to directive 2006/112/EC, the invoice shall be labelled as being a self-billed invoice and the requirements mentioned in article 224 of this directive shall be met. Self-billing may be introduced only if there is a prior agreement between the two parties and provided that a procedure exists for the acceptance of each invoice by the taxable person supplying the goods or services.

In case of self-billing, the Invoice type code shall be Self-billed invoice or Self-billed credit note. In this case the buyer will have legal responsibility for the invoice.

14.1 Invoicing functionality supported

14.1.1 Introduction

An invoice may support functions related to a number of related (internal) business processes. The core invoice model shall support the following functions:

— Accounting;

— Invoice verification against the contract, the purchase order and the goods and service delivered;

— VAT reporting;

— Auditing;

— Payment.

In this subclause 5.3, an assessment is made of what information is needed for each of the functions listed above and whether it is in scope or out of scope for the core invoice model. Functions that are in scope and thus are supported by the model have been assigned an identifier (e.g. R1) and have been given a description.

Explicit support for the following functions (but not limited to) is out of scope for the core invoice model although information elements in the core invoice model may provide some support for these functions:

— Inventory management;

— Delivery processes;

— Customs clearance;

— Marketing;

— Reporting.

The requirement identifiers are not necessarily consecutive or in sequence.

14.1.2 Accounting

Recording a business transaction into the financial accounts of an organization is one of the main objectives of the invoice. According to financial accounting best practice and VAT rules every Taxable person shall keep accounts in sufficient detail for VAT to be applied and its application checked by the tax authorities. For that reason, an invoice shall provide for the information at document and line level that enables booking on both the debit and the credit side.

In scope for the core invoice model:

R1	information at document level that enables the identification of the Payee, if different from the Seller (all processes, except P9);
R2	information at document level that enables booking on both the debit and the credit side (all processes);
R3	information at invoice line level that enables booking on the debit side (all processes);
R4	Buyer-specific booking information (account numbers) (all processes).

Out of scope for the core invoice model:

— invoice sub-lines;

— booking information at sub-line level.

14.1.3 Invoice verification

This process forms part of the Buyer’s internal business controls. The invoice shall refer to an authentic commercial transaction. Support for invoice verification is a key function of an invoice. The invoice should provide sufficient information to look up relevant existing documentation, electronic or paper, for example, and as applicable to the models detailed above:

— the relevant purchase order;

— the contract;

— the call for tenders, that was the basis for the contract;

— the Buyer’s reference;

— the confirmed receipt of the goods or services.

An invoice should also contain sufficient information that allows the received invoice to be transferred to a responsible authority, person or department, for verification and approval.

In scope for the core invoice model:

R5	information to trace to a single [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:08:00'FvB NOTE: '#50']related purchase orders from the document level (all processes, except P2 and P5);
R6	information to trace to a single related purchase order line from the invoice line (all processes, except P2 and P5);
R7	information to trace to a single contract and the underlying call for tenders from the document level (all processes, except P3 and P5);
R8	a reference supplied by the Buyer at document level (all processes);
R9	information to trace to a single [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:09:00'FvB NOTE: '#49']multiple despatch advices from the document level (processes P7 and P8);
R10	information to trace to a single [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:10:00'FvB NOTE: '#49']multiple receiving advices from the document level (process P8);
R11	information to trace to a related invoice to be corrected from the document level (process P10);
R12	reference to multiple part-invoices from a final invoice (process P12);
R13	information to allow an invoice and related documents to be transferred to a responsible authority, entity, person or department, for verification and approval (all processes);
R14	information about net price and the quantity on which the price is based at invoice line level, additional information such as gross price and price discount may be added (all processes);
R15	descriptive and coded information about allowances and charges at both document level and at invoice line level (all processes);
R16	information about charges, (non-VAT-)taxes, duties and levies, with their VAT information, that are not included in the line amounts at document level (all processes);
R17	information about charges, (non-VAT-)taxes, duties and levies that compose the taxable amount and are not included in the unit price at separate invoice lines, with a proper identification and/or description (all processes);
R18	information about charges at invoice line level as part of the line amount (all processes);
R19	the amounts of allowances and charges at document and invoice line level (all processes);
R20	textual descriptions of invoiced goods and services at invoice line level (all processes);
R21	identification of invoiced goods and services by means of a Seller's item number at invoice line level (all processes);
R22	identification of invoiced goods and services by means of a Buyer's item number at invoice line level (all processes);
R23	identification of invoiced goods and services by means of a qualified general item identifier at invoice line level as agreed by the Buyer and the Seller (all processes);
R24	classification of invoiced goods and services by means of applicable classification identifiers and schema reference as agreed between the Seller and the Buyer at invoice line level (all processes);
R25	information about returned and credited returnable assets or packages, such as pallets, and package charges, stated as normal invoice lines (all processes);
R26	information about returnable asset charges, stated as normal invoice lines (all processes);
R27	information about returned goods, stated as normal invoice lines (all processes);
R28	descriptive information about attributes of goods and services at invoice line level (all processes);
R29	information about the country of origin of goods and services at invoice line level (all processes);
R30	an invoice line period at invoice line level (process P2, P11);
R31	one delivery date at document level (all processes);
R32	one delivery location or address at document level (all processes);
R33	identification of the invoiced object at document and line level (process P2);
R34	a delivery/invoice period at document level (process P2, P11);
R35	attached documents of a limited set of file types (all processes);
R36	multiple attached or referenced documents at document level (all processes);
R37	a VAT category and rate at invoice line level (all processes);
R38	VAT totals per category at document level (all processes);
R39	a quantity and a net amount (exclusive of VAT) at invoice line level (all processes);
R40	all amounts at document and invoice line level that make up the invoice total amount and the amount due for payment (all processes);
R41	Reference to a sales order, issued by the Seller at document level (all processes);
R42	Allowance/charge percentage and base amount at document and invoice line level (all processes);
R44	Information to allow automated validation of a received electronic invoice (all processes).

Out of scope for the core invoice model:

— reference to multiple related purchase orders;
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:11:00'FvB
NOTE: '#50']

— reference to one or more related purchase order lines on header level;

— reference to multiple related purchase order lines on line level;

— reference to multiple contracts;

— reference to one or more price lists;

— reference to more than one despatch advice or shipping note;
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:11:00'FvB
NOTE: '#49']

— reference to the exact time of delivery;

— reference to one or more delivery notes, shipping notices or despatch advices or -lines at invoice line level;
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:11:00'FvB
NOTE: '#49']

[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:12:00'FvB
NOTE: '#49']— reference to more than one receiving advice;

— reference to one or more receiving advice lines at invoice line level;

— reference to supporting documents at invoice line level;

— reference to one or more consumption reports or performance records;

— reference to one or more invoices for payment in advance;

— reference to multiple sales orders (issued by the Seller);

— sub-lines of allowances and charges;

— delivered quantities of goods and services if different from invoiced quantities;

— ordered quantities of goods and services if different from invoiced quantities;

— back-ordered quantities of goods and services if different from invoiced quantities;

— coded attributes of goods and services;

— specific coded quality information of goods or services;

— structured metered values;

— lot numbers of goods and services (except in free text);

— serial numbers or other identification numbers (e.g. of the person rendering the services) (except in free text);

[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:12:00'FvB
NOTE: '#49']— reference to multiple deliveries;

— reference to a delivery at invoice line level
[ANNOTATION:

BY 'Sara Facchinetti'
ON '2020-11-13T17:50:00'SF
NOTE: '#49'].

VAT reporting

The invoice is used to carry VAT related information from the Seller to the Buyer to enable the Buyer and Seller to correctly handle VAT booking and reporting. An invoice should contain sufficient information to enable the Buyer and any auditor to determine whether the invoice is correct from a VAT point of view.

The invoice shall allow the determination of the VAT regime, the calculation and description of the tax, in accordance with the European Directive 2006/112/EC [2] and subsequent amendments. VAT reporting applies to all processes.

In scope for the core invoice model:

R45	information to determine the requirements of the applicable VAT legislation in force and the calculation and reporting thereof;
R46	information on the date the VAT is liable at document level;
R47	the necessary elements for national legal VAT requirements that apply for invoices issued to national and foreign Buyers, such as the legal registration status of the Seller;
R48	information to support the following VAT use cases:
	—	Invoices for supplies for which VAT is charged;
	—	Invoices for supplies for which VAT is not charged based on an exemption reason;
	—	Invoices for supplies for which the Seller’s goods and services are exempt from VAT at line level;
	—	Invoices for supplies that are issued under reverse charge;
	—	Invoices for exempt intra-community supplies for which an intra-community acquisition has to be done;
	—	Invoices for supplies outside the scope of the Directive 2006/112/EC [2] (non-VAT invoices);
R49	the total VAT amount at document level;
R50	total taxable amount per VAT rate at document level;
R51	any additional information required to support the exemption evidence in case VAT is not charged based on an exemption reason at document and at invoice line level;
R52	the legal registration number and the VAT registration number of the Seller and Buyer and the VAT registration number of the Tax representative of the Supplier;
R53	the official postal address of the Buyer, Seller and Tax representative of the Supplier and their place of business and registered office;
R54	the invoice currency and the VAT accounting currency at document level if different from the invoice currency;
R55	codes for exemption [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-15T08:39:00'FvB NOTE: '#23']and out of scope reasons at document and invoice line level.

Out of scope for the core invoice model:

— refund applications (Directive 2008/9/EC [5]);

— structured information that is commonly provided in page footnote of business documents, such as:

—share Capital Amount of the Seller;

—legal form of the Seller.

14.1.4 Auditing

Companies audit themselves as means of internal control or they may be audited by external parties as part of a legal obligation. Accounting is a regular, ongoing process whereas an audit is a separate review process to ensure that the accounting has been carried out correctly. The auditing process places certain information requirements on an invoice. These requirements are mainly related to enable verification of authenticity and integrity of the accounting transaction. Auditing requirements apply to all of the above processes.

Invoices, conformant to the core invoice model support the auditing process by providing sufficient information for:

— identification of the relevant Buyer and Seller;

— identification of the products and services traded, including description, value and quantity;

— information for connecting the invoice to its payment;

— information for connecting the invoice to relevant documents such as a contract and a purchase order.

In scope for the core invoice model:

R56

sufficient information to support the auditing process with regard to:

— identification of the invoice;

— identification of the date of issue of the invoice;

— identification of the products and services traded, including their description, value and quantity;

— information for relating the invoice to its settlement;

— information for relating the invoice to relevant documents such as a contract, a purchase order and a despatch advice;

— information about the reason for invoice correction (process P10);

R57

identification of the parties that fulfil the following roles at the invoice level, including their legal name and address:

— the Seller (including the Seller's trade name);

— the Buyer;

— the Deliver to party (if different from the Buyer);

— the Payee (if different from the Seller);

— the Tax representative of the Supplier;

Out of scope for the core invoice model:

— identification of:

—the carrier;

—the creditor (if different from Payee);

—the debtor (if different from Buyer);

—the identification of the service or business unit of the Seller, issued by the Buyer;

—subtotals for part of the lines.

14.1.5 Payment

An invoice represents a claim for payment. The issuance of an invoice may take place either before or after the payment is carried out. When an invoice is issued before payment it represents a request to the Buyer to pay, in which case the invoice commonly contains information that enables the Buyer, in the role of a debtor, to correctly initiate the transfer of the payment, unless that information is already agreed in prior contracts or by means of payment instructions separately lodged with the Buyer.

If an invoice is issued after payment, such as when the order process included payment instructions or when paying with a credit card, online or telephonic purchases, the invoice may contain information about the payment made in order to facilitate invoice to payment reconciliation on the Buyer side. An invoice may be partially paid before issuing such as when a pre-payment is made to confirm an order.

Invoices, conformant with the core invoice model should identify the means of payment for settlement of the invoice and clearly state what payment amount is requested. They should provide necessary details to support bank transfers in accordance with the Single Euro Payments Area (SEPA) for payments in Euro and the relevant national payment practices for other currencies. Payments by means of Credit Transfer, Direct debit, and Payment Card are in scope for making payments of invoices conformant with the core invoice model.

Payment information is needed in all processes.

In scope for the core invoice model:

R58	identification of the means of settlement;
R59	the requested amount due for payment;
R60	the date on which payment is due;
R61	necessary details to support bank transfers in accordance with SEPA and national systems;
R62	a reference number and any additional reference data to be included in the payment;
R63	reference number and any additional reference data to be included in the payment, in order to relate the payment to the invoice;
R64	information for relating an invoice to a payment card used for settlement;
R65	basic information to support national payment systems for use in domestic trade;
R66	information about the amount that was pre-paid;
R67	invoices that have a total amount of zero;
R68	invoices that have an amount to pay of zero;
R69	necessary details to support direct debits.
R70	pre-payment invoices

Out of scope for the core invoice model:

— instalments;

— references to pre-payments;

— early-payment allowances in a structured way;

— late-payment penalty schemes in a structured way;

— quoted or referenced structured payment terms.

14.1.6 Inventory

Invoices are sometimes used by the Buyer for placing goods into inventory, as replacement of more appropriate documents such as despatch advices or packing lists. Support for inventory management is not in scope of the core invoice model, although it is recognized that information provided for other processes, supported in the core invoice model, may be used for placing goods into inventory.

Out of scope for the core invoice model:

— information to support inventory management.

14.1.7 Delivery process

Invoices may be used by the business partners involved for: order picking, delivery instructions and receipt; as a replacement for more appropriate documents such as: Instructions to despatch, transport documents or packing lists. Specific support for delivery processes is however not in scope for the core invoice model and other appropriate electronic documents should be used.

Out of scope for the core invoice model:

— information to support the delivery process;

— delivery terms.

14.1.8 Customs clearance

When goods are cleared through customs, important information about the goods being cleared may be extracted from the invoice. Customs clearing may also require special information such as the origin of the items, materials used and other issues that may affect the classification and the calculation of import duties and taxes. For customs purposes an invoice may also contain the customs classification itself.

The core invoice model is not intended to specifically support customs clearance in general although information provided for other processes supported in the invoice may be used for customs purposes.

Out of scope for the core invoice model:

— specific support for customs clearance.

14.1.9 Marketing

Invoices may be used to deliver marketing messages to the Buyer in the form of text or as images, but no specific marketing information is within scope of the core invoice model.

Out of scope for the core invoice model:

— specific support for marketing.

14.1.10 Reporting

Invoices, such as utility invoices, frequently contain detailed information about usage of services that provide a breakdown of the total quantity in the invoice itself. No specific reporting information is within scope of the core invoice model itself but such information can be provided e.g. with attachments.

Out of scope for the core invoice model:

— specific reporting information.

14.2 The core invoice model in relation to other documents in the procurement process

An invoice, compliant with the core invoice model may reference only one
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:14:00'FvB
NOTE: '#50']multiple purchase orders and one
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:15:00'FvB
NOTE: '#49']multiple delivery deliveries explicitly. Such an invoice may still be used if only general, unqualified references to multiple purchase orders and/or deliveries suffice. For automatic processing of invoices, however,
[ANNOTATION:

BY 'Fred van Blommestein'
ON '2020-11-09T18:16:00'FvB
NOTE: '#49, #50']usually explicit, qualified references are needed. Alternatively, steps could be taken to change the business process and send one invoice per purchase order or delivery. This is especially in view of the convenience of electronic initiation for generating higher frequency invoicing.The core invoice model would need to be supplemented with use of an extension to support a process where multiple purchase orders and deliveries are to be invoiced with one invoice.

The relationships between the invoice and other documents and events are depicted in Figure 14. The listed documents should be interpreted in the scope of the relevant business processes, modelled in 5.2.

15 Figure 14 — Invoice relations

NOTE 1A Purchase order is an object that may be the result of exchanging a number of documents, such as confirmations and purchase order changes.

NOTE 2An invoice does, according to the core invoice model, not refer to each pre-payment event, but merely cites the total pre-paid amount.

6 The semantic data model of the core elements of an electronic invoice and credit note

15.1 Introduction

This Clause 6 describes the information elements, and groups of information elements, that constitutes the semantic data model of the core elements of an electronic Invoice, as well as their relationship and the business rules required to ensure the integrity and consistency in the data provided in a compliant instance document (an individual Invoice).

For an instance document to be compliant to the core invoice model, it shall respect all rules defined in this Clause 6.

It is the responsibility of the invoice issuer to ensure that an Invoice respects any rules defined by relevant legislation, including requirements related to personal data protection, as well as rules stated as part of a trading relationship between the Seller and the Buyer. An Invoice conforming to the rules of the semantic data model of the core elements of an electronic Invoice as described in this Clause 6 does not guarantee its legal compliance OR compliance to contractual obligations.

An overview of the groups of information elements contained in the semantic model is provided in Figure 15. Each of these groups and their detailed content is explained in detail in 6.2.

The business rules defined in order to ensure the integrity and consistency in the data provided in a compliant instance document can be found in 6.3.

The semantic data type assigned to individual information elements in the core invoice model to specify data format and metadata requirements that apply are detailed in 6.4.

Calculation examples are provided in 6.5.

NOTEThe figure only shows the information element groups. Individual information elements are not shown.

16Figure 15 — Overview of the semantic model

0.1 Legend

0.2 The semantic model

1 Table 2 — Semantic data model of the core elements of an electronic invoice

1.1 Business rules

1.1.1 Integrity constraints

2 Table 3 — Business rules - Integrity constraints

2.0.1 Conditions

3 Table 4 — Business rules – Conditions

3.0.1 VAT rules

3.0.1.1Introduction

Value added tax (VAT) is an important requirement for Invoices within the European Union. The detailed requirements for VAT are governed by the European Directive VAT Council Directive 2006/112/EC of the 28th November 2006. The Directive has been adopted by member states into their respective national legislation. It should be noted that there may be variations due to legislation in each member state.

The Directive specifies who (taxable parties) and what (items and services) are liable for VAT; how the VAT is calculated; and what information shall be present in Invoices when VAT is charged in the Invoice.

The Directive also includes several exception use cases when VAT is not charged in an Invoice.

The diagram in Figure 16 illustrates a summary of the VAT Requirement Model. Different cases of VAT are identified as VAT categories and identified in a coded way. The definition of the category codes is given later in this document.

4 Figure 16 — Summary of the VAT requirement model

4.0.0.1Specification of VAT category codes

In the table below the meaning of each VAT category code (based on the UNTDID 5305 code list [6]) is explained.

5 Table 5 — VAT categories

5.0.0.1VAT is levied through the Invoice

5.0.0.1.1Standard rate and reduced rate items

— The VAT category rate for the taxable amount is given as the relevant percentage rate;

— The VAT category taxable amount is the sum of Invoice line net amount minus the document level allowance amounts and plus the document level charge amounts;

— In the calculation of VAT the Invoice shall show a subtotal of the VAT taxable amount and the VAT tax amount for each VAT rate (i.e. each combination of the category code S and VAT tax rate on line level and for allowance and charges on document level).

5.0.0.1.2Business rules statements

6 Table 6 — Business rules - VAT standard and reduced rate

6.0.0.1VAT is not levied through the Invoice

6.0.0.1.1Zero rated sale

While sale which is rated zero does not attract a VAT charge, there is, however, a requirement to state that the sale is zero rated. For each sale, recorded at Invoice line as well as document level allowances and charges the VAT shall be identified as follows.

— In the calculation of VAT, the Invoice shall show the amount taxed as zero rated as a subtotal of line amounts for lines that have VAT category code Zero rated sale;

— In the calculation of VAT, the Invoice shall show on document level the VAT charged as zero rated as the taxable amount multiplied by the percentage rate. Since by definition the rate is 0 % the VAT amount shall be zero.

6.0.0.1.2Business rules statements

7 Table 7 — Business rules - VAT zero rate

7.0.0.0.1Exempted from VAT

As shown in the diagram above there are situations where sales are exempted from VAT. These are cases where VAT is not levied in the Invoice.

Sales may be exempt from VAT due to various reasons in accordance to EU directives and/or national legislation. When sales are exempt from VAT for various general reasons the following information shall be given:

— free text description of the reason for exemption shall be given for each exempted Invoice line;

— free text description of the reason for exemption shall be given in the VAT breakdown;

— in the calculation of VAT the Invoice shall on document level show the VAT charged as zero rated as the taxable amount multiplied by the percentage rate. Since by definition the rate is 0 % the VAT amount shall be zero.

8 Table 8 — Business rules - Exempted from VAT

8.0.0.0.1Reverse Charge

When VAT is not levied in an Invoice due to Reverse Charge the following data are applied in the Invoice. As both the Seller and the Buyer have an agreement to apply the reverse charge, both the Buyer and Seller shall be registered for VAT and the VAT registration numbers of both the Buyer and Seller shall be detailed in the Invoice.

Where reverse charging applies, both the Buyer and Seller shall be registered for VAT, the VAT registration numbers of both the Buyer and Seller shall be detailed in the Invoice, and the statement “reverse charge” shall be present in the invoice. An issuer of an Invoice is required to indicate when an Invoice line is a reverse charge. In the Invoice this is done by using the VAT category code for Reverse charge from code list subset of UN/TDID 5305 in relevant Invoice line.

In the electronic Invoice existence of the code for Reverse charge constitutes a declaration that the Invoice line is a reverse charge but to comply with regulation the text “Reverse charge” shall also appear in the Exemption reason / out of scope text.

— the text “Reverse charge” is given for the VAT exemption / out of scope reason text in the VAT breakdown (Or the equivalent standard text in other languages).

— the Invoiced item VAT category code for the line is given as Reverse charge;

— the text “Reverse charge” is given for the invoiced item VAT exemption / out of scope reason text (or the equivalent standard text in other languages).

It is the responsibility of the Seller to Invoice as reverse charge when appropriate. The following rules do not verify if that decision is correct. They only check whether the information is correctly stated in the Invoice instance.

9 Table 9 — Business rules - VAT reverse charge

9.0.0.0.1Intra-Community Supply

When VAT is not levied in an Invoice due to Intra-Community Supply the following information is included in the Invoice. As both the Seller and the Buyer have an agreement to apply the intra-community supply, both the Buyer and Seller shall be registered for VAT and the VAT registration numbers of both the Buyer and Seller shall be detailed in the Invoice.

An issuer of an Invoice is required to indicate when an Invoice line is an intra-community supply. In the Invoice this is done by using the VAT tax category code for Intra-Community from code list subset of UN/TDID 5305 in relevant Invoice line.

In the electronic Invoice the existence of the code for Intra-community supply constitutes a declaration that the Invoice line is an intra-community supply but to comply with regulation, the text “Intra-community supply” shall also appear in the Exemption / out of scope reason text.

— the text “Intra-community supply” is given for the VAT exemption / out of scope reason text in the VAT breakdown (or the equivalent standard text in other languages).

— the text “Intra-community supply” in the invoiced item exemption / out of scope reason text (or the equivalent standard text in other languages).

It is the responsibility of the Seller to Invoice as Intra-community Supply when appropriate. The following rules do not verify if that decision is correct. They only check whether the information is correctly stated in the Invoice instance.

10 Table 10 — Business rules - VAT intra-community supply

10.0.0.0.1Exports

When VAT is not levied in an Invoice due to exports out of EU the following information is included in the Invoice.

An issuer of an Invoice is required to indicate when an Invoice line is export outside of EU. In the Invoice this is done by using the VAT tax category for Exports from code list subset of UN/TDID 5305 in the relevant Invoice line.

— the text “Exports outside the EU” is given for the VAT exemption / out of scope reason text in the VAT breakdown (or the equivalent standard text in other languages).

— the text “Exports outside the EU” in the Invoice line exemption / out of scope reason text (or the equivalent standard text in other languages).

It is the responsibility of the Seller to Invoice as exports when appropriate. The following rules do not verify if that decision is correct. They only check whether the information is correctly stated in the Invoice instance.

11 Table 11 — Business rules - VAT exports

11.0.0.0.1Not subject to VAT

When a sale is not subject to VAT, the entire Invoice shall not be subject to VAT .(Directive 2006/112/EC [2], article 16, second paragraph).

12 Table 12 — Business rules - Not subject to VAT

12.0.0.0.1Canary Islands, Ceuta and Melilla tax

In some European regions, taxes are applicable that are equivalent to VAT and need much the same processing. These taxes are in effect in the Canary Islands (IGIC) and in Ceuta and Melilla (IPSI). The following rules apply.

13 Table 13 — Business rules - Canary Islands tax

14 Table 14 — Business rules - Ceuta and Melilla tax

15Table XX — Business rules – Specific national regulation

15.1Semantic data types

15.1.1 Introduction

16 Table 15 — Primitive types

16.0.1 Amount. Type

17 This EN 16931_ Amount. Type is based on the Amount. Type as defined in ISO 15000 5:2014, Annex B. EN 16931_ Amount. Type is floating up to two fraction digits.

18 Table 16 — Data type -– Amount. Type

18.0.1Unit Price Amount. Type

A unit price amount states a numerical monetary amount value for data elements that contain item prices that may be multiplied by item quantities. The currency of the amount is defined as a separate business term. This EN 16931_ Unit Price_ Amount. Type is based on the Amount. Type as defined in ISO 15000‑5:2014, Annex B. EN 16931_ Unit Price_ Amount. Type is floating with no limits to the number of fraction digits

19 Table 17 — Data type - Unit price amount. Type

19.0.1 Quantity. Type

20 Table 18 — Data type - Quantity. Type

20.0.1 Percentage. Type

21 Table 19 — Data type - Percentage. Type

21.0.1 Identifier. Type

22 Table 20 — Data type - Identifier. Type

22.0.1 Document Reference. Type

23 Table 21 — Data type - Document Reference. Type

23.0.1 Code. Type

24 Table 22 — Data type - Code. Type

24.0.1 Date. Type

25 Table 23 — Data type - Date. Type

25.0.1Time. Type

26Table xx — Data type - Time. Type

26.0.2Text. Type

Text is the actual wording of anything written or printed. This EN 16931_ Text. Type is based on the Text. Type as defined in ISO 15000‑5:2014, Annex B. Line breaks in the text may be present.

27 Table 24 — Data type - Text. Type

27.0.1 Binary Object. Type

28 Table 25 — Data type - Binary Object. Type

28.0.1 Decimals

29 Table 26 — Allowed number of decimals

29.0.1 Rounding

29.1 Introduction

29.2 Compliance

29.3 What may be specified in a CIUS

29.3.1 Introduction

29.3.2 Allowed specifications in a CIUS

29.4 Documentation of core invoice usage specifications

29.5 Mapping to syntax

29.6 Identification of core invoice usage specifications

30 Table C.1 — References to directive articles

falseereffalse0false0false _id="b2"[2] Council Directive. 2006/112/EC of 28 November 2006 on the common system of value added tax – last version: 2006L0112 - EN - 01.01.2015 - 016.001 [viewed 2015-07-26] Available from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02006L0112-20150101.falseereffalse

falseereffalse0false0false _id="b3"[3] Directive 2011/7/EU of the European Parliament and of the Council of 16 February 2011 on combating late payment in commercial transactions [viewed 2015-07-26] Available from http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32011L0007.falseereffalse

falseereffalse0false0false _id="b4"[4] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data [viewed 2015-07-26]. Available from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=URISERV:l14012.falseereffalse

falseereffalse0false0false _id="b5"[5] Council Directive. 2008/9/EC of 12 February 2008 laying down detailed rules for the refund of value added tax, provided for in Directive 2006/112/EC, to taxable persons not established in the Member State of refund but established in another Member State [viewed 2015-07-26]. Available from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32008L0009&qid=1437940645512.falseereffalse

falseereffalse0false0false _id="b8"[8] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC [viewed 2015-07-26]. Available from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910.falseereffalse

falseereffalse0false0false _id="b10"[10] Annex to the Commission Implementing Decision C. (2014)7912 final of 10 December 2014 on a standardisation request to the European standardisation organizations as regards a European standard on electronic invoicing and a set of ancillary standardisation deliverables pursuant to Regulation (EU) No 1025/2012 of the European Parliament and of the Council [viewed 2015-07-26]. Available from http://ec.europa.eu/DocsRoom/documents/8650/attachments/1/translations/en/renditions/pdf.falseereffalse

falseereffalse0false0false _id="b12"[12] Object Management Group - Business Process Model and Notation v2, http://www.omg.org/spec/BPMN/2.0/falseereffalse

falsestdfalse0false0false _id="b20"[20] ISO 639‑2, Codes for the representation of names of languages — Part 2: Alpha-3 codefalsestdfalse

ID	Description	Target / context	Business term / group
BR-1	An Invoice shall have a Specification identifier (BT-24).	Process control	BT-24
BR-2	An Invoice shall have an Invoice number (BT-1).	Invoice	BT-1
BR-3	An Invoice shall have an Invoice issue date (BT-2).	Invoice	BT-2
BR-4	An Invoice shall have an Invoice type code (BT-3).	Invoice	BT-3
BR-5	An Invoice shall have an Invoice currency code (BT-5).	Invoice	BT-5
BR-6	An Invoice shall contain the Seller name (BT-27).	Seller	BT-27
BR-7	An Invoice shall contain the Buyer name (BT-44).	Buyer	BT-44
BR-8	An Invoice shall contain the Seller postal address (BG-5).	Seller	BG-5
BR-9	The Seller postal address (BG-5) shall contain a Seller country code (BT-40).	Seller Postal Address	BT-40
BR-10	An Invoice shall contain the Buyer postal address (BG-8).	Buyer	BG-8
BR-11	The Buyer postal address shall contain a Buyer country code (BT-55).	Buyer Postal Address	BT-55
BR-12	An Invoice shall have the Sum of Invoice line net amount (BT-106).	Document totals	BT-106
BR-13	An Invoice shall have the Invoice total amount without VAT (BT-109).	Document totals	BT-109
BR-14	An Invoice shall have the Invoice total amount with VAT (BT-112).	Document totals	BT-112
BR-15	An Invoice shall have the Amount due for payment (BT-115).	Document totals	BT-115
BR-16	An Invoice shall have at least one Invoice line (BG-25).	Invoice	BG-25
BR-17	The Payee name (BT-59) shall be provided in the Invoice, if the Payee (BG-10) is different from the Seller (BG-4).	Payee	BT-59
BR-18	The Seller tax representative name (BT-62) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11).	Seller tax representative	BT-62
BR-19	The Seller tax representative postal address (BG-12) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11).	Seller tax representative	BG-12
BR-20	The Seller tax representative postal address (BG-12) shall contain a Tax representative country code (BT-69), if the Seller (BG-4) has a Seller tax representative party (BG-11).	Seller tax representative postal address	BT-69
BR-21	Each Invoice line (BG-25) shall have an Invoice line identifier (BT-126).	Invoice Line	BT-126
BR-22	Each Invoice line (BG-25) shall have an Invoiced quantity (BT-129).	Invoice Line	BT-129
BR-23	An Invoice line (BG-25) shall have an Invoiced quantity unit of measure code (BT-130).	Invoice Line	BT-130
BR-24	Each Invoice line (BG-25) shall have an Invoice line net amount (BT-131).	Invoice Line	BT-131
BR-25	Each Invoice line (BG-25) shall contain the Item name (BT-153).	Item information	BT-153
BR-26	Each Invoice line (BG-25) shall contain the Item net price (BT-146).	Price details	BT-146
BR-27	The Item net price (BT-146) shall NOT be negative.	Item net price	BT-146
BR-28	The Item gross price (BT-148) shall NOT be negative.	Price details	BT-148
BR-29	If both Invoicing period start date (BT-73) and Invoicing period end date (BT-74) are given then the Invoicing period end date (BT-74) shall be later or equal to the Invoicing period start date (BT-73).	Invoicing Period	BT-74
BR-30	If both Invoice line period start date (BT-134) and Invoice line period end date (BT-135) are given then the Invoice line period end date (BT-135) shall be later or equal to the Invoice line period start date (BT-134).	Invoice Line Period	BT-135
BR-31	Each Document level allowance (BG-20) shall have a Document level allowance amount (BT-92).	Document level allowances	BT-92
BR-32	Each Document level allowance (BG-20) shall have a Document level allowance VAT category code (BT-95).	Document level allowances	BT-95
BR-33	Each Document level allowance (BG-20) shall have a Document level allowance reason (BT-97) or a Document level allowance reason code (BT-98).	Document level allowances	BT-97, BT-98
BR-36	Each Document level charge (BG-21) shall have a Document level charge amount (BT-99).	Document level charges	BT-99
BR-37	Each Document level charge (BG-21) shall have a Document level charge VAT category code (BT-102).	Document level charges	BT-102
BR-38	Each Document level charge (BG-21) shall have a Document level charge reason (BT-104) or a Document level charge reason code (BT-105).	Document level charges	BT-104, BT-105
BR-41	Each Invoice line allowance (BG-27) shall have an Invoice line allowance amount (BT-136).	Invoice line allowances	BT-136
BR-42	Each Invoice line allowance (BG-27) shall have an Invoice line allowance reason (BT-139) or an Invoice line allowance reason code (BT-140).	Invoice line allowances	BT-144, BT-145
BR-43	Each Invoice line charge (BG-28) shall have an Invoice line charge amount (BT-141).	Invoice line charges	BT-141
BR-44	Each Invoice line charge (BG-28) shall have an Invoice line charge reason (BT-144) or an Invoice line charge reason code (BT-145).	Invoice line charges	BT-139, BT-140
BR-45	Each VAT breakdown (BG-23) shall have a VAT category taxable amount (BT-116).	VAT breakdown	BT-116
BR-46	Each VAT breakdown (BG-23) shall have a VAT category tax amount (BT-117).	VAT breakdown	BT-117
BR-47	Each VAT breakdown (BG-23) shall be defined through a VAT category code (BT-118).	VAT breakdown	BT-118
BR-48	Each VAT breakdown (BG-23) shall have a VAT category rate (BT-119), except if the Invoice is not subject to VAT.	VAT breakdown	BT-119
BR-49	A Payment instruction (BG-16) shall specify the Payment means type code (BT-81).	Payment instructions	BT-81
BR-50	[ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#12']A Payment account identifier (BT-84) shall be present if Payment Type Code (BT-81) means “Credit Transfer”.A Payment account identifier (BT-84) shall be present if Credit transfer (BG-16) information is provided in the Invoice.	Account information	BT-84
BR-51	The last 4 to 6 digits of the Payment card primary account number (BT-87) shall be present if Payment card information (BG-18) is provided in the Invoice.	Card information	BT-87
BR-52	Each Additional supporting document (BG-24) shall contain a Supporting document reference (BT-122).	Additional supporting documents	BT-122
BR-53	If the VAT accounting currency code (BT-6) is present, then the Invoice total VAT amount in accounting currency (BT-111) shall be provided.	Document totals	BT-111
BR-54	Each Item attribute (BG-32) shall contain an Item attribute name (BT-160) and an Item attribute value (BT-161).	Item attributes	BT-160, BT-161
BR-55	Each Preceding Invoice reference (BG-3) shall contain a Preceding Invoice reference (BT-25).	Preceding invoice reference	BT-25
BR-56	Each Seller tax representative party (BG-11) shall have a Seller tax representative VAT identifier (BT-63).	Seller tax representative	BT-63
BR-57	Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80).	Deliver to address	BT-80
BR-61	If the Payment means type code (BT-81) means SEPA credit transfer, Local credit transfer or Non-SEPA international credit transfer, the Payment account identifier (BT-84) shall be present.	Payment instructions	BT-84
BR-62	The Seller electronic address (BT-34) shall have a Scheme identifier.	Seller electronic address	BT-34
BR-63	The Buyer electronic address (BT-49) shall have a Scheme identifier.	Buyer electronic address	BT-49
BR-64	The Item standard identifier (BT-157) shall have a Scheme identifier	Item standard identifier	BT-157
BR-65	The Item classification identifier (BT-158) shall have a Scheme identifier	Item classification identifier	BT-158
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#14']BR-XX66	If the invoice has one or more attachments, the attachment details shall be specified in Attached documents (BT-125) and the invoice receiver shall be warned that the processing of a structured attachment requires the knowledge of its semantics.	Attached documents	BT-125
[ANNOTATION: BY 'Fred van Blommestein' ON '2021-03-17T17:41:00'FvB NOTE: '#41']BR-XX67	If Invoice line net amount (BT-131) is negative EITHER the Invoiced quantity (BT-129) shall be negative OR Invoice line allowances (BG-27) shall be greater than Invoice line charges (BG-28) plus line price (Item net price BT-146/ Item price base quantity BT-149* x Invoiced quantity BT-129).\|Invoice line \|BT-131.	Invoice line net amount	BT-131

ID	Description	Target / context	Business term / group
BR-CO-3	Value added tax point date (BT-7) and Value added tax point date code (BT-8) are mutually exclusive.	Invoice	BT-7, BT-8
BR-CO-4	Each Invoice line (BG-25) shall be categorized with an Invoiced item VAT category code (BT-151).	Invoice Line	BT-151
BR-CO-5	Document level allowance reason code (BT-98) and Document level allowance reason (BT-97) shall indicate the same type of allowance.	Document level Allowances	BT-97, BT-98
BR-CO-6	Document level charge reason code (BT-105) and Document level charge reason (BT-104) shall indicate the same type of charge.	Document level Charges	BT-104, BT-105
BR-CO-7	Invoice line allowance reason code (BT-140) and Invoice line allowance reason (BT-139) shall indicate the same type of allowance reason.	Invoice line Allowances	BT-139, BT-140
BR-CO-8	Invoice line charge reason code (BT-145) and Invoice line charge reason (BT144) shall indicate the same type of charge reason.	Invoice line Charges	BT-144, BT-145
BR-CO-9	The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166‑1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.	VAT identifiers	BT-31, BT-48, BT-63
BR-CO-10	Sum of Invoice line net amount (BT-106) = ∑shall be the sum of Invoice line net amount (BT- [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T10:14:00'FvB NOTE: '#2']131) with a tolerance of 0,01.	Document totals	BT-106
BR-CO-11	[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-13T18:20:00'SF NOTE: '#2' NOTE: '']Sum of allowances on document level (BT-107) = ∑shall be the sum of Document level allowance amount (BT-92) with a tolerance of 0,01.	Document totals	BT-107
BR-CO-12	[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-13T18:03:00'SF NOTE: '#2']Sum of charges on document level (BT-108) = ∑shall be the sum of Document level charge amount (BT-99) with a tolerance of 0,01.	Document totals	BT-108
BR-CO-13 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:26:00'FvB NOTE: '#2, #8, #46']	Invoice total amount without VAT (BT-109) = ∑ Invoice line net amount (BT-131) - Sum of allowances on document level (BT-107) + Sum of charges on document level (BT-108).	Document totals	BT-109
BR-CO-XXX26	The VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall be equal to the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category code (BT-118) and the VAT category rate (BT-119), and where applicable the exemption / out of scope reason code (BT-XXX168, BT-XXX171 and BT-XXX184) and the exemption reason text (BT-XXX167, BT-XXX170 and BT-XXX183) are identical with the VAT category exemption / out of scope reason code (BT-120) and VAT category exemption / out of scope reason text (BT-121), rounded to 2 decimals with a tolerance of 0,01. [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:41:00'FvB NOTE: '#2']
BR-CO-XXX27	The VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) should be equal to the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category code (BT-118) and the VAT category rate (BT-119), and where applicable the exemption / out of scope reason code (BT-168, BT-171 and BT-184)(BT-XXX, BT-XXX and BT-XXX) and the exemption / out of scope reason text (BT-167, BT-170 and BT-183)(BT-XXX, BT-XXX and BT-XXX) are identical with the VAT category exemption / out of scope reason code (BT-120) and VAT category exemption / out of scope reason text (BT-121), rounded to 2 decimals. [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:41:00'FvB NOTE: '#2']
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:31:00'FvB NOTE: '#8']BR-CO-XX28	Invoice total amount without VAT (BT-109) shall be equal to the sum of VAT category taxable amounts (BT-116)	Document totals	BT-109
BR-CO-14	Invoice total VAT amount (BT-110) = ∑ VAT category tax amount (BT-117).	Document totals	BT-110
BR-CO-15	Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110) .)X– Amount withheld (BT-XX [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:40:00'FvB NOTE: '#29']	Document totals	BT-112
BR-CO-16	Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) - ∑ Paid amount (BT-113 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:40:00'FvB NOTE: '#29']– ∑ Amount withheld (BT-172).+ Rounding amount (BT-114).	Document totals	BT-115
BR-CO-17	VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals.	VAT breakdown	BT-117
BR-CO-18	An Invoice shall at least have one VAT breakdown group (BG-23).	VAT breakdown	BG-23
BR-CO-19	If Invoicing period (BG-14) is used, the Invoicing period start date (BT-73) or the Invoicing period end date (BT-74) shall be filled, or both.	Delivery or invoice period	BT-73, BT-74
BR-CO-20	If Invoice line period (BG-26) is used, the Invoice line period start date (BT-134) or the Invoice line period end date (BT-135) shall be filled, or both.	Invoice line period	BT-134, BT-135
BR-CO-21	Each Document level allowance (BG-20) shall contain a Document level allowance reason (BT-97) or a Document level allowance reason code (BT-98), or both.	Document level allowance	BT-97, BT-98
BR-CO-22	Each Document level charge (BG-21) shall contain a Document level charge reason (BT-104) or a Document level charge reason code (BT-105), or both.	Document level charge	BT-104, BT-105
BR-CO-23	Each Invoice line allowance (BG-27) shall contain an Invoice line allowance reason (BT-139) or an Invoice line allowance reason code (BT-140), or both.	Invoice line allowance	BT-139, BT-140
BR-CO-24	Each Invoice line charge (BG-28) shall contain an Invoice line charge reason (BT-144) or an Invoice line charge reason code (BT-145), or both.	Invoice line charge	BT-144, BT-145
BR-CO-25	In case the Amount due for payment (BT-115) is positive, either the Payment due date (BT-9) or the Payment terms (BT-20) shall be present.	Invoice	BT-9, BT-20
BR-CO-26	In order for the buyer to automatically identify a supplier, the Seller identifier (BT-29), the Seller legal registration identifier (BT-30) and/or the Seller VAT identifier (BT-31) shall be present.	Seller	BT-29, BT-30, BT-31
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T14:12:00'FvB NOTE: '#42']BR-CO-XX29	The Item price base quantity (BT-149) shall NOT be negative.	Price details	BT-149
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T14:42:00'FvB NOTE: '#18, #40']BR-CO-XX30	Invoice line net amount (BT-131) shall be equal to ((Item net price (BT-146) ÷ Item price base quantity (BT-149)) x Invoiced quantity (BT-129) + ∑ Invoice line charge amount (BT-141) – ∑ Invoice line allowance amount (BT-136) with a tolerance of 0,01.	Invoice line net amount	BT-131
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T14:42:00'FvB NOTE: '#18, #40']BR-CO-XX31	Invoice line net amount (BT-131) should be equal to ((Item net price (BT-146) ÷ Item price base quantity (BT-149)) x Invoiced quantity (BT-129) + ∑ Invoice line charge amount (BT-141) – ∑ Invoice line allowance amount (BT-136).	Invoice line net amount	BT-131
BR-CO-32	[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T12:30:00'SF NOTE: '#29']If Tax withheld indicator is equal to “Yes” at Document Allowance level (BT-XXX) or Document Charge level (BT-XXX) or Line level (BT-XXX) at least one Tax withheld (BG-XX) shall be present.

Definition of category	Category
Standard VAT calculation
Item is liable for VAT that is calculated in a standard way of applying the VAT percentage to the relevant taxable amount.	Standard rate
Item is liable for VAT that is calculated in a standard way of applying the VAT percentage to the relevant taxable amount, but the VAT percentage rate is 0 (zero).	Zero rated
VAT is not levied due to trade circumstances
Item is exempt from VAT.	Exempt
The VAT tax is not levied to an item that is liable for VAT due to trade circumstances where the Reverse charge VAT rules apply.	Reverse charge
The VAT is not levied to an item that is liable for VAT due to trade circumstances where the rules on Intra-community supply apply.	Intra-community supply
The VAT is not levied to an item that is liable for VAT due to trade circumstances where the rules on export outside of the EU apply.	Export
Other VAT taxes apply
Sale is subject to Canary Island (IGIC) tax.	IGIC
Sale is subject to Ceuta and Melilla (IPSI) tax.	IPSI
[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:59:00'SF NOTE: '#20']Sale is subject to a specific national regulation where normal VAT calculation does not apply	XX
Not subject to VAT
Sale is not subject to VAT.	Not subject to VAT
Transferred VAT
[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:59:00'SF NOTE: '#39']VAT not to be paid to the issuer of the invoice but directly to relevant tax authority (for Italian split payment)	Transferred

ID	Description
BR-S-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Standard rated” shall contain in the VAT breakdown (BG-23) at least one VAT category code (BT-118) equal with "Standard rated".
BR-S-2	An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Standard rated” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-S-3	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Standard rated” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-S-4	An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Standard rated” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-S-5	In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Standard rated" the Invoiced item VAT rate (BT-152) shall be greater than zero.
BR-S-6	In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Standard rated" the Document level allowance VAT rate (BT-96) shall be greater than zero.
BR-S-7	In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Standard rated" the Document level charge VAT rate (BT-103) shall be greater than zero.
BR-S-8	.For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) is “Standard rated” and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119) [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:40:00'FvB NOTE: '#2']
BR-S-9	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "Standard rated" shall be equal to the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119), with a tolerance of 1.
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T09:57:00'FvB NOTE: '#2']BR-S-X	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "Standard rated" should be equal to the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119).
BR-S-10	A VAT Breakdown (BG-23) with VAT Category code (BT-118) "Standard rate" shall not have a VAT exemption / out of scope reason code (BT-121) or VAT exemption / out of scope reason text (BT-120).
BR-S-11	[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T17:46:00'SF NOTE: '#26']Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Standard rated" shall not have a Invoiced item VAT exemption / out of scope reason text (BT-XXX183) or Invoiced item VAT exemption / out of scope reason code (BT-XXX184)

ID	Description
BR-Z-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Zero rated” shall contain in the VAT breakdown (BG-23) exactly one VAT category code (BT-118) equal with "Zero rated".
BR-Z-2	An Invoice that contains an Invoice line where the Invoiced item VAT category code (BT-151) is “Zero rated” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-Z-3	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Zero rated” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-Z-4	An Invoice that contains a Document level charge where the Document level charge VAT category code (BT-102) is “Zero rated” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-Z-5	In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Zero rated" the Invoiced item VAT rate (BT-152) shall be 0 (zero).
BR-Z-6	In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Zero rated" the Document level allowance VAT rate (BT-96) shall be 0 (zero).
BR-Z-7	In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Zero rated" the Document level charge VAT rate (BT-103) shall be 0 (zero).
BR-Z-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:07:00'FvB NOTE: '#2']	In a VAT breakdown (BG-23) where VAT category code (BT-118) is "Zero rated" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amount (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Zero rated".
BR-Z-9	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "Zero rated" shall equal 0 (zero).
BR-Z-10	A VAT Breakdown (BG-23) with VAT Category code (BT-118) "Zero rated" shall not have a VAT exemption / out of scope reason code (BT-121) or VAT exemption / out of scope reason text (BT-120).
BR-Z-11	[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T17:46:00'SF NOTE: '#26']Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Zero rated" shall not have a Invoiced item VAT exemption / out of scope reason text (BT-XXX184) or Invoiced item VAT exemption / out of scope reason code (BT-XXX184)

ID	Description
BR-E-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Exempt from VAT” shall contain exactly [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T13:59:00'FvB NOTE: '#9'] at least one VAT breakdown (BG-23) with the VAT category code (BT-118) equal to "Exempt from VAT": one per exemption reason (BT-120, BT-121, BT-XXX167, BT-XXX168, BT-XXX170, BT-XXX171) or one for all exemption reasons combinedBT-XXX, BT- XXX)(or one per exemption reason at line level [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#9'] [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T12:50:00'SF NOTE: '#26'] .
BR-E-2	An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Exempt from VAT” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-E-3	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Exempt from VAT” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-E-4	An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Exempt from VAT” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-E-5	In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Exempt from VAT", the Invoiced item VAT rate (BT-152) shall be 0 (zero).
BR-E-6	In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Exempt from VAT", the Document level allowance VAT rate (BT-96) shall be 0 (zero).
BR-E-7	In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Exempt from VAT", the Document level charge VAT rate (BT-103) shall be 0 (zero).
BR-E-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:07:00'FvB NOTE: '#2']	In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Exempt from VAT".
BR-E-9	The VAT category tax amount (BT-117) In a VAT breakdown (BG-23) where the VAT category code (BT-118) equals "Exempt from VAT" shall equal 0 (zero).
BR-E-10	A VAT Breakdown (BG-23) with VAT Category code (BT-118) "Exempt from VAT" shall have a VAT exemption / out of scope reason code (BT-121) or a VAT exemption reason /out of scope text (BT-120).

ID	Description
BR-AE-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Reverse charge” shall contain in the VAT breakdown (BG-23) exactly at least one VAT category code (BT-118) [ANNOTATION: BY 'Fred van Blommestein' ON '2021-02-05T11:12:00'FvB NOTE: '#26']per exemption reason (BT-120, BT-121, BT-XXX167, BT-XXX168, BT-XXX170, BT-XXX171) or one for all exemption reasons combined equal with "VAT reverse charge".
BR-AE-2	An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Reverse charge” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and/or the Buyer legal registration identifier (BT-47).
BR-AE-3	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Reverse charge” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and/or the Buyer legal registration identifier (BT-47).
BR-AE-4	An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Reverse charge” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and/or the Buyer legal registration identifier (BT-47).
BR-AE-5	In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Reverse charge" the Invoiced item VAT rate (BT-152) shall be 0 (zero).
BR-AE-6	In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Reverse charge" the Document level allowance VAT rate (BT-96) shall be 0 (zero).
BR-AE-7	In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Reverse charge" the Document level charge VAT rate (BT-103) shall be 0 (zero).
BR-AE-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:07:00'FvB NOTE: '#2']	In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Reverse charge" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Reverse charge".
BR-AE-9	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where the VAT category code (BT-118) is “Reverse charge” shall be 0 (zero).
BR-AE-10	A VAT Breakdown (BG-23) with VAT Category code (BT-118) "Reverse charge" shall have a VAT exemption reason / out of scope code (BT-121), meaning "Reverse charge" or the VAT exemption reason / out of scope text (BT-120) "Reverse charge" (or the equivalent standard text in another language).

ID	Description
BR-IC-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Intra-community supply” shall contain in the VAT breakdown (BG-23) exactly at least one VAT category code (BT-118) [ANNOTATION: BY 'Fred van Blommestein' ON '2021-02-05T11:13:00'FvB NOTE: '#26']per exemption reason (BT-120, BT-121, BT-167, BT-168, BT-170, BT-171)(BT-120, BT-121, BT-XXX, BT-XXX, BT-XXX, BT-XXX) or one for all exemption reasons combined equal with "Intra-community supply".
BR-IC-2	An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Intra-community supply” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48).
BR-IC-3	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Intra-community supply” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48).
BR-IC-4	An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Intra-community supply” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48).
BR-IC-5	In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Intra-community supply" the Invoiced item VAT rate (BT-152) shall be 0 (zero).
BR-IC-6	In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Intra-community supply" the Document level allowance VAT rate (BT-96) shall be 0 (zero).
BR-IC-7	In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Intra-community supply" the Document level charge VAT rate (BT-103) shall be 0 (zero).
BR-IC-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:08:00'FvB NOTE: '#2']	In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Intra-community supply" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Intra-community supply".
BR-IC-9	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where the VAT category code (BT-118) is “Intra-community supply” shall be 0 (zero).
BR-IC-10	A VAT Breakdown (BG-23) with the VAT Category code (BT-118) "Intra-community supply" shall have a VAT exemption / out of scope reason code (BT-121), meaning "Intra-community supply" or the VAT exemption reason / out of scope text (BT-120) "Intra-community supply" (or the equivalent standard text in another language).
BR-IC-11	In an Invoice with a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Intra-community supply" the Actual delivery date (BT-72) or the Invoicing period (BG-14) shall not be blank.
BR-IC-12	In an Invoice with a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Intra-community supply" the Deliver to country code (BT-80) shall not be blank.

ID	Description
BR-G-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Export outside the EU” shall contain in the VAT breakdown (BG-23) exactly at least one VAT category code (BT-118) [ANNOTATION: BY 'Fred van Blommestein' ON '2021-02-05T11:14:00'FvB NOTE: '#26']per exemption reason (BT-120, BT-121, BT-XXX167, BT-XXX168, BT-XXX170, BT-XXX171) or one for all exemption reasons combined equal with "Export outside the EU".
BR-G-2	An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Export outside the EU” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63).
BR-G-3	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Export outside the EU” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63).
BR-G-4	An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Export outside the EU” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63).
BR-G-5	In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Export outside the EU" the Invoiced item VAT rate (BT-152) shall be 0 (zero).
BR-G-6	In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Export outside the EU" the Document level allowance VAT rate (BT-96) shall be 0 (zero).
BR-G-7	In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Export outside the EU" the Document level charge VAT rate (BT-103) shall be 0 (zero).
BR-G-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:08:00'FvB NOTE: '#2']	In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Export outside the EU" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Export outside the EU".
BR-G-9	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where the VAT category code (BT-118) is “Export outside the EU” shall be 0 (zero).
BR-G-10	A VAT Breakdown (BG-23) with the VAT Category code (BT-118) "Export outside the EU" shall have a VAT exemption / out of scope reason code (BT-121), meaning "Export outside the EU" or the VAT exemption / out of scope reason text (BT-120) "Export outside the EU" (or the equivalent standard text in another language).

ID	Description
BR-O-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Not subject to VAT” shall contain [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T13:33:00'FvB NOTE: '#10']at leastexactly one VAT breakdown group (BG-23) with the VAT category code (BT-118) equal to "Not subject to VAT": one per exemption reason (BT-120, BT-121, BT-XXX167, BT-XXX168, BT-XXX170, BT-XXX171) or one for all exemption reasons combinedor one per exemption reason at line level (BT-XXX, BT- XXX) [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T12:55:00'SF NOTE: '#26'] [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T12:50:00'SF NOTE: '#26'] .
BR-O-2 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10, #22']	An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Not subject to VAT” shall not contain the Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer VAT identifier (BT-46).
BR-O-3 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10, #22']	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Not subject to VAT” shall not contain the Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer VAT identifier (BT-48).
BR-O-4 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10, #22']	An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Not subject to VAT” shall not contain the Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer VAT identifier (BT-48).
BR-O-5	An Invoice line (BG-25) where the VAT category code (BT-151) is "Not subject to VAT" shall not contain an Invoiced item VAT rate (BT-152).
BR-O-6	A Document level allowance (BG-20) where VAT category code (BT-95) is "Not subject to VAT" shall not contain a Document level allowance VAT rate (BT-96).
BR-O-7	A Document level charge (BG-21) where the VAT category code (BT-102) is "Not subject to VAT" shall not contain a Document level charge VAT rate (BT-103).
BR-O-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:08:00'FvB NOTE: '#2']	In a VAT breakdown (BG-23) where the VAT category code (BT-118) is " Not subject to VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Not subject to VAT".
BR-O-9	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where the VAT category code (BT-118) is “Not subject to VAT” shall be 0 (zero).
BR-O-10	A VAT Breakdown (BG-23) with VAT Category code (BT-118) " Not subject to VAT" shall have a VAT exemption / out of scope reason code (BT-121), meaning " Not subject to VAT" or a VAT exemption / out of scope reason text (BT-120) " Not subject to VAT" (or the equivalent standard text in another language) [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T13:35:00'FvB NOTE: '#10']possibly with more detail.
BR-O-11 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10']	An Invoice that contains a VAT breakdown group (BG-23) with a VAT category code (BT-118) "Not subject to VAT" shall not contain other VAT breakdown groups (BG-23).
BR-O-12 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10']	An Invoice that contains a VAT breakdown group (BG-23) with a VAT category code (BT-118) "Not subject to VAT" shall not contain an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is not "Not subject to VAT".
BR-O-13 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10']	An Invoice that contains a VAT breakdown group (BG-23) with a VAT category code (BT-118) "Not subject to VAT" shall not contain Document level allowances (BG-20) where Document level allowance VAT category code (BT-95) is not "Not subject to VAT".
BR-O-14 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10']	An Invoice that contains a VAT breakdown group (BG-23) with a VAT category code (BT-118) "Not subject to VAT" shall not contain Document level charges (BG-21) where Document level charge VAT category code (BT-102) is not "Not subject to VAT".

ID	Description
BR-IG-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “IGIC” shall contain in the VAT breakdown (BG-23) at least one VAT category code (BT-118) equal with "IGIC".
BR-IG-2	An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “IGIC” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-IG-3	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “IGIC” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-IG-4	An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “IGIC” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-IG-5	In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "IGIC" the invoiced item VAT rate (BT-152) shall be 0 (zero) or greater than zero.
BR-IG-6	In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "IGIC" the Document level allowance VAT rate (BT-96) shall be 0 (zero) or greater than zero.
BR-IG-7	In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "IGIC" the Document level charge VAT rate (BT-103) shall be 0 (zero) or greater than zero.
BR-IG-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:09:00'FvB NOTE: '#2']	For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "IGIC", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) is “IGIC” and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119).
BR-IG-9	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "IGIC" shall be equal to the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119) [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T10:00:00'FvB NOTE: '#2']with a tolerance of 1.
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T10:00:00'FvB NOTE: '#2']BR-IG-X	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "IGIC" should be equal to the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119).
BR-IG-10	A VAT Breakdown (BG-23) with VAT Category code (BT-118) "IGIC" shall not have a VAT exemption / out of scope reason code (BT-121) or VAT exemption / out of scope reason text (BT-120).
BG-IG-11	[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T17:46:00'SF NOTE: '#26']Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "IGIC" shall not have a Invoiced item VAT exemption / out of scope reason text (BT-XXX183) or Invoiced item VAT exemption / out of scope reason code (BT-XXX184)

ID	Description
BR-IP-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “IPSI” shall contain in the VAT breakdown (BG-23) at least one VAT category code (BT-118) equal with "IPSI".
BR-IP-2	An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “IPSI” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-IP-3	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “IPSI” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-IP-4	An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “IPSI” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-IP-5	In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "IPSI" the Invoiced item VAT rate (BT-152) shall be 0 (zero) or greater than zero.
BR-IP-6	In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "IPSI" the Document level allowance VAT rate (BT-96) shall be 0 (zero) or greater than zero.
BR-IP-7	In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "IPSI" the Document level charge VAT rate (BT-103) shall be 0 (zero) or greater than zero.
BR-IP-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:09:00'FvB NOTE: '#2']	For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "IPSI", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) is “IPSI” and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119).
BR-IP-9	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "IPSI" shall be equal to the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119) [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T10:01:00'FvB NOTE: '#2']with a tolerance of 1.
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T10:02:00'FvB NOTE: '#2']BR-IP-X	The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "IPSI" should be equal to the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119).
BR-IP-10	A VAT Breakdown (BG-23) with VAT Category code (BT-118) "IPSI" shall not have a VAT exemption / out of scope reason code (BT-121) or VAT exemption / out of scope reason text (BT-120).
BR-IP-11	[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T17:46:00'SF NOTE: '#26']Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "IPSI" shall not have a Invoiced item VAT exemption / out of scope reason text (BT-XXX183) or Invoiced item VAT exemption / out of scope reason code (BT-XXX184)

[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T17:34:00'FvB NOTE: '#20']ID	Description
BR-XX-1	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “XX” shall contain in the VAT breakdown (BG-23) at least one VAT category code (BT-118) equal with "XX".
BR-XX-2	An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “XX” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-XX-3	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “XX” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-XX-4	An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “XX” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63).
BR-XX-10	A VAT Breakdown (BG-23) with VAT Category code (BT-118) "XX" shall have a VAT exemption / out of scope reason code (BT-121) or VAT exemption / out of scope reason text (BT-120).

Primitive type	Definition
Binary	A set of finite-length sequences of binary digits.
Date	Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar [ISO 8601:2004].
Decimal	A subset of the real numbers, which can be represented by decimal numerals.
String	A finite sequence of characters.

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	10000.,25

	— A Pool is the graphical representation of a Participant in a Collaboration. It also acts as a “swim lane” and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations.
	— A Lane is a sub-partition within a Process within a Pool, and will extend the entire length of the Process. Lanes are used to organize and categorize Activities.
	— An Activity is a generic term for work that an organization performs in a Process. Activities are represented by rounded rectangles. An Activity can be atomic (no icon inside) or non-atomic (compound: with a small plus sign near the bottom). Activities that consist of sending a message have a black envelope in the upper right corner. Activities that consist of receiving a message have a white envelope in the upper right corner.
	— A message is represented as an envelope.
	— Circles represent events. An event that starts a process has a thin border; an event that ends a process has a thick border
	— Diamond shapes represent gateways indicating the type of flow control behaviour. The types of control include: • Exclusive decision and merging (no icon in the diamond); • Parallel Gateway forking and joining (a plus sign inside the diamond); • Complex Gateway; complex conditions and situations, e.g. 3 out of 5 (a star inside the diamond).
	— Message flows are indicated with a dotted arrow.
	— Sequence flows are indicated with an arrow.
	— Conversations (multiple communication flows that are not further detailed) are indicated with a double line.

BT ID	Business term name	Allowed maximum number of decimals
BT-166	[ANNOTATION: BY 'Sara Facchinetti' ON '2021-02-09T17:53:00'SF NOTE: '#45']Amount to be paid	2
BG-20	DOCUMENT LEVEL ALLOWANCES
BT-92	Document level allowance amount	2
BT-93	Document level allowance base amount	2
BG-21	DOCUMENT LEVEL CHARGES
BT-99	Document level charge amount	2
BT-100	Document level charge base amount	2
BG-22	DOCUMENT TOTALS
BT-106	Sum of Invoice line net amount	2
BT-107	Sum of allowances on document level	2
BT-108	Sum of charges on document level	2
BT-109	Invoice total amount without VAT	2
BT-110	Invoice total VAT amount	2
BT-112	Invoice total amount with VAT	2
BT-111	Invoice total VAT amount in accounting currency	2
BT-113	Paid amount	2
BT-114	Rounding amount	2
BT-115	Amount due for payment	2
BT-172	Amount withheld	[ANNOTATION: BY 'Sara Facchinetti' ON '2021-02-09T17:44:00'SF NOTE: '#29']2
BT-173	Withheld base amount	[ANNOTATION: BY 'Sara Facchinetti' ON '2021-02-09T17:44:00'SF NOTE: '#29']2
BG-23	VAT BREAKDOWN
BT-116	VAT category taxable amount	2
BT-117	VAT category tax amount	2
BG-25	INVOICE LINE
BT-131	Invoice line net amount	2
BG-27	INVOICE LINE ALLOWANCES
BT-136	Invoice line allowance amount	2
BT-137	Invoice line allowance base amount	2
BG-28	INVOICE LINE CHARGES
BT-141	Invoice line charge amount	2
BT-142	Invoice line charge base amount	2

Type of change	Example/remark
Business Terms
Mark conditional Information element not to be used	Can be achieved by changing cardinality 0..x to 0..0. This essentially means that an element which use is conditional is not to be used. This will not affect the receivers processing. Care need to be taken to ensure that the business rules defined for the core invoice model are not broken.
Make semantic definition narrower	A narrower semantic definition of a business term means that the meaning conveyed is still within the meaning defined in the core invoice model and is already recognized by the receiver.
Add synonyms	As synonyms will only supplement the original business terms but do not replace it - the original term is still normative. A receiver who has designed his processing based on the core invoice model can continue to do so. Examples of synonyms are mapping of national or sector terminology to the terminology used in the core invoice.
Add explanatory text	Adding explanatory text that, for example, explains how a business term is used in a specific use case. There is a risk that such text may also affect the semantic definition and this shall be avoided. Explanatory information does not require any further action from the receiver and the automatic processing of the assigned invoice is still possible.
Cardinality
Make a conditional element mandatory (0..x – > 1..x)	If a conditional element is made mandatory it simply means that the option of using it is applied. The receiver shall be prepared for the situation that a conditional element is used, so he does not need to modify his processing.
Decrease number of repetitions (x..n – > x..1)	If the number of repetitions is decreased they will remain within the limit that the receiver has catered for.
Semantic data type
Change semantic data type from string to ...	If the semantic data type of a business term is changed from string to some other type the receiver can still process the value as a string.
Codes and identifiers
Remove one of multiple defined lists	Where the core invoice semantic model defines more than one allowed list and the core invoice usage specification reduces the number of allowed lists then the invoice instance document is still compliant. However such a change shall leave at least one of the defined lists in place.
Mark defined values as not allowed	If the allowed code values are restricted within an existing list it simply means that certain values of the full list are being used and the receiver should have designed for processing them.
Business Rules
Add new non-conflicting business rule for existing element(s)	Represents an additional restriction on the allowed content within what is defined for the core invoice model. The receiver should therefore have designed for that content.
Make an existing business rule more restrictive	The exchanged content of the business term remains within what was defined for the core invoice model and the receiver should have designed for it.
Value domain for an element
Restrict text or byte array length	If a maximum is set on the length where there was no limit the content remains within what was defined for the core invoice model.
Require defined structured values	When the core invoice model does not set a structure on a value the receiver would not have designed for processing in any particular form. Rules to enforce a given pattern should therefore not affect his processing.
Restrict allowed fraction digits	Fewer fraction digits result in a value that is within the accuracy that the receiver would have designed for when implementing the core invoice model.

ID	Standardization Request Item			Relevance			Risk		Conclusion
1.1	Standardization Request Text:			LOW			LOW		MET
	The work should take into account the European Interoperability Framework (EIF), and the interoperability solutions created under the ISA programme.’
1.1.1	Discussion
	Based on its knowledge of the EIF4, CEN/TC 434 agreed in advance that a reactive approach should be taken with respect to the specific recommendations of the EIF, with the framework being considered as a point of reference and taken into account as and when the TC encountered potentially serious issues which appeared to be impacted. No such issues came to light during the work.
1.1.2	Assessment of the draft EN with respect to this Standardization Request requirement
	Based on TC434 task force’s knowledge and the high level nature of the vision expressed in the EIF, whose philosophy has already been embedded in much recent standardization work such as in the source standards for the EN, no specific further requirements for the EN were anticipated to be necessary. The EN is fully aligned with the EIF.
ID	Standardization Request Item	Relevance			Risk			Conclusion
1.2	Standardization Request Text:	MEDIUM			MEDIUM			MET
	The new Regulation on electronic identification and trust services (e-IDAS) for electronic transactions in the internal market with due respect to its date of entry into force.
1.2.1	Discussion
	Where used by trading parties, advanced electronic signatures or seals are relevant to the EN as by definition, they uniquely identify and link its signatory or seal creator to the content (authenticity of origin) and will invalidate the signature or the seal if the signed data has been tampered with (integrity of data). Advanced electronic signatures or seals can be technically implemented as described in Commission Implementing Decision (EU) 2015/1506 of 8 September 2015 laying down specifications relating to formats of advanced electronic signatures and advanced seals to be recognized by public sector bodies pursuant to Articles 27(5) and 37(5) of eIDAS Regulation. It establishes that XAdES, PAdES, CAdES and the associated containers shall be supported by Member States. The signature or the seal should always be applied to the transmitted payload so that the authenticity and integrity of the invoice can be verified during the whole legal archiving period and for confidentiality purposes. At the message or header level, the transmitted message could be also signed or sealed (e.g. when sent using the AS2 protocol), for the whole or during a stage or stages of the transmission process, but the use of signatures or seals in these circumstances is separate from its use to ensure authenticity and integrity. The requirements of the e-IDAS Regulation as stated above are important in the transmission layer for invoice delivery and for archiving purposes. They have no impact on invoice content as defined in the EN.
1.2.2	Assessment of the draft EN with respect to this Standardization Request requirement
	There are no implications for the Semantic Data Model for the draft EN arising from the e-IDAS Regulation.
ID	Standardization Request Item	Relevance			Risk				Conclusion
1.3.	Standardization Request Text:	MEDIUM			MEDIUM				MET
	The results of Large Scale Pilot (LSP) projects implemented within the framework of the ICT Policy Support Programme (ICT-PSP) under the umbrella of the Competitiveness and Innovation Framework Programme (CIP).
1.3.1	Discussion
	Liaisons were established with the LSP projects and relevant experts participated in the work of CEN/TC 434.
1.3.2	Assessment of the draft EN with respect to this Standardization Request requirement
	No issues came to light as a result of the above-mentioned liaisons.
ID	Standardization Request Item		Relevance			Risk			Conclusion
1.4	Standardization Request Text:		MEDIUM			MEDIUM			MET
	The Digital Service Infrastructure (DSI) on e-invoicing to be deployed in the framework of the Connecting Europe Facility (CEF).
1.4.1	Discussion
	Liaisons were established with the CEF programme and ongoing discussion took place through CEF participation in the work of CEN/TC 434.
1.4.2	Assessment of the draft EN with respect to this Standardization Request requirement
	Since the CEF DSI e-invoicing initiative is a rolling effort fully supportive of the EN, and is not focused on standards design, no impact is foreseen.

ID	Business Term	Description	2014/55/EU [1]	2006/112/EC amended by 2010/45/EC
BT-1	Invoice number	A unique identification of the Invoice.	Art 6 a	Art 226 2
BT-2	Invoice issue date	The date when the Invoice was issued.		Art 226 1
BT-5	Invoice currency code	The currency in which all Invoice amounts are given, except for the Total VAT amount in accounting currency.	Art 6 l	Art 230
BT-6	VAT accounting currency	The currency used for VAT accounting and reporting purposes as accepted or required in the country of the seller.		Art 230
BT-7	Value added tax point date	The date when the VAT Becomes accountable for the Seller and for the Buyer in so far as that date can be determined and differs from the date of issue of the invoice.		Art 226 7
BT-8	Value added tax point date code	The VAT point date according to Art. 63 - 67		Art. 227 7a, Art. 63 - 67
BT-9	Payment due date	The date when the payment is due.	2011/7/EU [3]
BT-12	Contract identifier	The identification of a contract.	Art 6 g
BT-20	Payment terms	A textual description of the payment terms that apply to the amount due for payment (Including description of possible penalties).	2011/7/EU [3]
BG-2	PROCESS CONTROL	A group of business terms providing information on the business process and rules applicable to the Invoice document.	Art 6 a
BG-3	PRECEDING INVOICE REFERENCE	A group of business terms providing information on one or more preceding Invoices.		Art 219
BG-4	SELLER	A group of business terms providing information about the seller.	Art 6 c
BT-27	Seller name	The full formal name by which the Seller is registered in the national registry of legal entities or as a Taxable person or otherwise trades as a person or persons.		Art 226 5
BT-31	Seller VAT identifier	The Seller's VAT identifier (also known as Seller VAT identification number).		Art 226 3
BT-32	Seller tax registration	The local identification of the Seller for tax purposes or a reference that enables the Seller to state his registered tax status.		Art 239
BG-5	SELLER POSTAL ADDRESS	A group of business terms providing information about the address of the Seller.		Art 226 5
BG-6	SELLER CONTACT	A group of business terms providing contact information about the Seller.	Art 6 c
BG-7	BUYER	A group of business terms providing information about the Buyer.	Art 6 d
BT-44	Buyer name	The full name of the Buyer.		Art 226 5
BT-49	Buyer electronic address	Identifies the Buyer's electronic address to which the invoice is delivered.	2011/7/EU [3]
BT-48	Buyer VAT identifier	The Buyer's VAT identifier (also known as Buyer VAT identification number).		Art 226 4
BG-8	BUYER POSTAL ADDRESS	A group of business terms providing information about the postal address for the Buyer.		Art 226 5
BG-9	BUYER CONTACT	A group of business terms providing contact information relevant for the Buyer.	Art 6 d
BG-10	PAYEE	A group of business terms providing information about the payee, i.e. the role that receives the payment.	Art 6 e
BG-11	SELLER TAX REPRESENTATIVE PARTY	A group of business terms providing information about the Seller's tax representative.	Art 6 f	Art 226 15
BG-12	SELLER TAX REPRESENTATIVE POSTAL ADDRESS	A group of business terms providing information about the postal address for the tax representative party.		Art 226 15
BG-13	DELIVER TO INFORMATION	A group of business terms providing information about where and when the goods and services invoiced are delivered.	Art 6 h
BG-14	DELIVERY OR INVOICE PERIOD	A group of business terms providing information on the delivery or invoice period.	Art 6 b
BG-15	DELIVER TO ADDRESS	A group of business terms providing information about the address to which goods and services invoiced were or are delivered.	Art 6 h
BG-16	PAYMENT INSTRUCTIONS	A group of business terms providing information about the payment.	Art 6 i
BG-17	CREDIT TRANSFER	A group of business terms to specify credit transfer payments.	Art 6 i
BG-18	PAYMENT CARD INFORMATION	A group of business terms providing information about card used for payment contemporaneous with invoice issuance.	Art 6 i
BG-20	DOCUMENT LEVEL ALLOWANCES	A group of business terms providing information about allowances applicable to the Invoice as a whole.	Art 6 j
BG-21	DOCUMENT LEVEL CHARGES	A group of business terms providing information about charges and taxes other than VAT, applicable to the Invoice as a whole.	Art 6 j
BG-22	DOCUMENT TOTALS	A group of business terms providing the monetary totals for the Invoice.	Art 6 l
BT-110	Invoice total VAT amount	The total VAT amount for the Invoice.		Art 226 10
BT-111	Invoice total VAT amount in accounting currency	The VAT total amount expressed in the accounting currency accepted or required in the country of the Seller.		Art 230
BT-115	Amount due for payment	The outstanding amount that is requested to be paid.	2011/7/EU [3]
BG-23	VAT BREAKDOWN	A group of business terms providing information about VAT breakdown by different categories, rates and exemption reasons	Art 6 m	Art 226 8
BT-119	VAT category rate	The VAT rate, represented as percentage that applies for the relevant VAT category.		Art 226 9
BT-120	VAT exemption / out of scope reason text	A textual statement of the reason why the amount is exempted from VAT or why no VAT is being charged		Art 226 11 to 14
BG-25	INVOICE LINE	A group of business terms providing information on individual Invoice lines.	Art 6 k
BG-26	INVOICE LINE PERIOD	A group of business terms providing information about the Invoice period relevant for the Invoice line.	Art 6 b
BG-27	INVOICE LINE ALLOWANCES	A group of business terms providing information about allowances applicable to the individual Invoice line.	Art 6 j
BG-28	INVOICE LINE CHARGES	A group of business terms providing information about charges and taxes other than VAT applicable to the individual Invoice line.	Art 6 j
BG-29	PRICE DETAILS	A group of business terms providing information about the price applied for the goods and services invoiced on the Invoice line.	Art 6 k
BG-30	LINE VAT INFORMATION	A group of business terms providing information about the VAT applicable for the goods and services invoiced on the Invoice line.	Art 6 m	Art 226 8
BG-31	ITEM INFORMATION	A group of business terms providing information about the goods and services invoiced.	Art 6 k
BG-32	ITEM ATTRIBUTES	A group of business terms providing information about properties of the goods and services invoiced.	Art 6 k
BG-31	ITEM INFORMATION	nature of the goods supplied or the extent and nature of the services rendered		Art. 226 (6)
BT-153	Item name
BT-154	Item description
BT-155	Item Seller's identifier
BT-156	Item Buyer's identifier
BT-157	Item standard identifier
BT-158	Item classification code
BT-159	Item country of origin

1Scope

2Normative references

3Terms and definitions

4The concept of a core invoice

16Figure 15 — Overview of the semantic model

3.0.1.1Introduction

4.0.0.1Specification of VAT category codes

5.0.0.1VAT is levied through the Invoice

5.0.0.1.1Standard rate and reduced rate items

5.0.0.1.2Business rules statements

6.0.0.1VAT is not levied through the Invoice

6.0.0.1.1Zero rated sale

6.0.0.1.2Business rules statements

7.0.0.0.1Exempted from VAT

8.0.0.0.1Reverse Charge

9.0.0.0.1Intra-Community Supply

10.0.0.0.1Exports

11.0.0.0.1Not subject to VAT

12.0.0.0.1Canary Islands, Ceuta and Melilla tax

15Table XX — Business rules – Specific national regulation

15.1Semantic data types

18.0.1Unit Price Amount. Type

25.0.1Time. Type

26Table xx — Data type - Time. Type

26.0.2Text. Type

1 Scope

2 Normative references

3 Terms and definitions

4 The concept of a core invoice